User / Group Permissions

When a user connects to the Vitalware server:

A valid username and password must be entered.
Vitalware searches the Registry for the username to determine the group(s) to which the user belongs.
If the user has not been assigned to a group, a search is performed for the Default group.
If a Default group does not exist, the user cannot access Vitalware.

By default, Vitalware contains Registry entries for the following groups:

Admin - highly privileged users with access to all Vitalware components, functionality and data.
Default

An Administrator can create other groups as required. Often these groups reflect a particular business section within the organisation.

Vitalware also contains support for many other types of user groups. Some examples are:

`Counter`	Counter Staff who work on a counter till.
`Mailroom`	Mailroom Staff who work on a mailroom till.

The assignment of permissions and privileges to users in Vitalware is thus determined by group membership:

Permissions are assigned to groups.
-AND-
Each user is a member of one or more groups and inherits the permissions of the group(s) to which they belong.

Group-based permissions are simpler to manage and more efficient than assigning permissions to individual users as a single group Registry entry can apply to multiple users. They also tend to promote a more secure system:

Assigning permissions to groups reduces complexity by limiting the number of Registry entries required. The less complex the system of permissions, the more likely it is that your users have the permissions you intend and therefore that your system is secure.
A change to a group permission applies to every member of the group without the need to update permissions for each user individually.

A group is created in one of two ways:

With the Group Registry entry we assign a user to a group. To create a new group called Managers for instance, we simply assign a user to a group called Managers:
User fred Group Managers
When this Group Registry entry is set, a group called Managers will be created but it will have no permissions assigned to it specifically (only default permissions will apply to members of the new group).
We can also create a group by assigning permissions to it. Permissions assigned to a group determine:
- What modules can be accessed.
- What tabs in a module are available.
- Permissions for each field within each tab.
- Operations that can be performed, e.g. add records, delete records.
For instance, we could create a new group called Managers by assigning Column Access permissions to a group that we name as Managers:
Group Managers Table eparties Column Access Default dvDisplay;dvEdit;dvQuery;duQuery
When this Column Access Registry entry is set, a group called Managers will be created but it will have no users assigned to it until they are assigned using the Group Registry entry.

A group is referenced by its group name, which can be any label, although a descriptive label that captures the main activity of the group members is suggested (e.g. Registrations). A group name may contain spaces.

Note: There may be times when it is necessary to assign permissions to individual users in order to override a setting assigned to a group that the user is a member of. For example, a group may be allowed to insert new records in a module, but a specific user in that group may be restricted to read-only permissions for the module. The use of group-based permissions to manage the default privileges for users means that only the differences between group permissions and any user specific permissions need to be defined for a user. Do not forget that user and group permissions for the same Registry entry are not cumulative: a user Registry entry overrides the equivalent group Registry entry. See The order in which Registry entries are assigned for details.